cc @jarondl Unfortunately I need to revert your PR.

I have just realized that this results in the cpu_usage of the process not working, since this relies on caching the previous values of CPU times.

Please feel free to resubmit your PR if you can find a solution around this.

cc @danielnelson

Yikes. So gopsutil only gives correct cpu times if you keep using the same object?

That's correct, and it's not possible for gopsutil to workaround this. Calculating CPU usage inherently requires two "cpu time" readings, which is why the first collection of CPU metrics never has any usage fields defined.

Well the correct (but backwards incompatible) way to architecture this is to save cumulative cpu time itself.
Then the dashboard / alerting tool can calculate the cpu usage (e.g. grafana's non_negative_derivative)

The other benefit of this scheme is that even if you miss a read you don't miss a cpu usage spike.

Could be useful to have a cpu_time metric, but I think we will also want a simple to graph stat like the cpu_usage. We should be able to recreate processes only for pids that change, I doubt the pid would be reused so quickly as to not be detected.

@jarondl CPU time -> % usage isn't quite that simple and is platform-specific, I think it would be a bit abnormal for a data collector that doesn't do the usage calculation itself.

We do already provide the raw time metrics if you want them, but we fielddrop them by default.